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DETAILED ACTION 

1 . The instant application having Application No. 10/763,872 filed on January 23, 
2004 is presented for examination by the examiner. 

Examiner Notes 

2. Examiner cites particular columns and line numbers in the references as applied 
to the claims below for the convenience of the applicant. Although the specified citations 
are representative of the teachings in the art and are applied to the specific limitations 
within the individual claim, other passages and figures may apply as well. It is 
respectfully requested that, in preparing responses, the applicant fully consider the 
references in entirety as potentially teaching all or part of the claimed invention, as well 
as the context of the passage as taught by the prior art or disclosed by the examiner 

Oath/Declaration 

3. The applicant's oath/declaration has been reviewed by the examiner and is found 
to conform to the requirements prescribed in 37 C.F.R. 1 .63. 

Priority 

4. As required by M.P.E.P. 201.14(c), acknowledgement is made of applicant's 
claim for priority based on applications filed on March 10, 2003. 

5. Receipt is acknowledged of papers submitted under 35 U.S.C. 1 1 9(a)-(d), which 
papers have been placed of record in the file. 



Application/Control Number: 10/763,872 Page 3 

Art Unit: 2436 

Information Disclosure Statement 

6. As required by M.P.E.P. 609, the applicant's submissions of the Information 
Disclosure Statement dated February 8, 2006 is acknowledged by the examiner and the 
cited references have been considered in the examination of the claims now pending. 

Drawings 

7. The applicant's drawings submitted are acceptable for examination purposes. 

Claim Objections 

8. Claim 7 is objected to because of the following informalities: In line 13 it recites 
"an authentication success packet" which should read "an authentication failure packet". 
Appropriate correction is required. 

Claim Rejections - 35 USC §101 

9. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

10. Claim 13 is rejected under 35 U.S.C. 101 as directed to non-statutory subject 
matter of software, perse. While the claim recites an "apparatus," the "apparatus" is not 
recited in terms of hardware or tangible structural elements. Rather, the "apparatus" 
could be a software system, where the elements are implemented solely in software or 
algorithms. Thus, the claim(s) lack(s) the necessary physical articles or objects to 
constitute a machine or manufacture within the meaning of 35 U.S.C. 101 . It/they is/are 
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clearly not a series of steps or acts to be a process nor is/are it/they a combination of 
chemical compounds to be a composition of matter. As such, it/they fail(s) to fall within a 
statutory category. It/they is/are at best, functional descriptive material. 

Claim 14 is rejected under 35 U.S.C. 101 as non-statutory for at least the reason 
stated above. Claim 14 is dependent upon claim 13; however, it does not add any 
feature or subject matter that would solve any of the non-statutory deficiencies of claim 

Claim Rejections - 35 USC §102 

1 1 . The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

12. Claims 13 and 14 are rejected under 35 U.S.C. 102(b) as being anticipated by 
"OAM in Frames" (hereinafter "Gentry"). 

As to claim 13, Gentry teaches an authentication apparatus in an Ethernet 
passive optical network (EPON) comprising: 

a bus interface for inputting data from an external router, and outputting data to 
the external router (page 9, the CO (OLT) inherently using a bus interface); 

a control unit for receiving an OAM (Operation, Administration and Maintenance) 
packet in accordance with an authentication process and to control data services for an 
optical network unit (ONU) (page 9, this being the OLT); and 
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a downstream unit for switching data received via the bus interface under control 
of the control unit (page 19, this being an OLT acting as link "B", "C", or "D"). 

As to claim 14, Gentry teaches wherein the control unit controls a switching 
operation of a downstream port included in the downstream unit, based on the received 
OAM packet, a logical link ID (LLID) and an ACT (Authentication Control Table) and 
according to an ALTM (Address Lookup Table Management) protocol (page 8 and page 
19, the PHY ID (LLID) being used to route to the next link when a port is authenticated 
(i.e. in the ACT)). 

Claim Rejections - 35 USC §103 

1 3. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

14. Claims 1-2, 7-8, 15-16, and 18-19 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over "Authentication and Privacy in EPON" (hereinafter "Kim") in view of 
U.S. Patent No. 6,070,243 (hereinafter "See"). 

As to claim 1, Kim teaches an authentication method in an Ethernet passive 
optical network (EPON) comprising the steps of: 
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(A) causing an optical line terminal (OLT) to receive, from an optical network unit 
(ONU), a packet informing of the start of an authentication process, and, responsive to 
that receipt, controlling the OLT to transmit, to the ONU, a packet for requesting an 
identifier of the ONU (page 13, this being the EAPOL-Start and EAP request(who) 
messages respectively); 

(B) causing the OLT to receive from the ONU the identifier and to compare the 
identifier to a previously stored value to determine whether the identifier corresponds to 
the previously stored value (page 13, this being the EAP Response/ld(mylD) and the 
ONU's ID (i.e. identifier) is pre-registered (i.e. previously stored)); 

(C) transmitting an authentication success packet to the ONU when it is 
determined at the step (B) that the correspondence exists (page 13, this being one 
possible EAP Success/Failure message); and 

(D) transmitting an authentication failure packet to the ONU when it is determined 
at the step (B) that the correspondence does not exist (page 13, this being the other 
possible EAP Success/Failure message), but does not specifically teach (E) after 
completion of the step (C) or (D), controlling the OLT to inform the ONU that an 
authentication process has ended. 

However, See teaches (E) after completion of the step (C) or (D), controlling the 
OLT to inform the ONU that an authentication process has ended (column 6, lines 22- 
30, this being the authentication session termination message). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to send an explicit indication that 
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authentication has ended as in See because this would allow the ONU to begin to fix an 
authentication problem (if a failure) or begin regular communications (if a success). 

As to claim 2, Kim teaches wherein the identifier of the ONU is a username (page 
13, the ONU's pre-registered ID being a username). 

As to claim 7, Kim teaches an authentication method in an Ethernet passive 
optical network (EPON) comprising the steps of: 

(A) controlling an optical network unit (ONU) to transmit, to an optical line 
terminal (OLT), a packet informing of the start of an authentication process, and causing 
the ONU to receive, from the OLT, a packet for requesting an identifier of the ONU 
(page 13, this being the EAPOL-Start and EAP request(who) messages respectively); 

(B) controlling the ONU to transmit to the OLT the identifier of the ONU (page 1 3, 
this being the EAP Response/ld(mylD)); 

(C) receiving at the ONU an authentication success packet in response to 
transmission of the authentication success packet when it is determined that a 
correspondence exists between the identifier and a value previously stored in the OLT, 
and proceeding with processing at the ONU based on that determination (page 13, this 
being one possible EAP Success/Failure message and the ONU's ID (i.e. identifier) is 
pre-registered (i.e. previously stored)); and 

(D) receiving at the ONU an authentication success packet in response to 
transmission of the authentication failure packet when it is determined that the 
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correspondence does not exist, and proceeding with processing at the ONU based on 
the determination that the correspondence does not exist (page 13, this being the other 
possible EAP Success/Failure message), but does not specifically teach (E) causing the 
ONU to receive, from the OLT, a packet informing that an authentication process has 
ended, the informing packet being sent as a result of said determination of the step (C) 
or (D). 

However, See teaches (E) causing the ONU to receive, from the OLT, a packet 
informing that an authentication process has ended, the informing packet being sent as 
a result of said determination of the step (C) or (D) (column 6, lines 22-30, this being the 
authentication session termination message). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to send an explicit indication that 
authentication has ended as in See because this would allow the ONU to begin to fix an 
authentication problem (if a failure) or begin regular communications (if a success). 

As to claim 8, Kim teaches wherein the identifier of the ONU is a username (page 
13, the ONU's pre-registered ID being a username). 

As to claim 15, Kim teaches a computer-readable recording medium having, 
recorded within, a program executable by a processor of an optical line terminal (OLT) 
of an Ethernet passive optical network (EPON), the program comprising: 
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(A) instructions which, when executed by said processor, cause the OLT to 
receive, from an optical network unit (ONU), a packet informing of the start of an 
authentication process, and, responsive to that receipt, controlling the OLT to transmit, 
to the ONU, a packet for requesting an identifier of the ONU (page 13, this being the 
EAPOL-Start and EAP request(who) messages respectively); 

(B) instructions which, when executed by said processor, cause the OLT to 
receive from the ONU the identifier and to compare the identifier to a previously stored 
value to determine whether the identifier corresponds to the previously stored value 
(page 13, this being the EAP Response/ld(mylD) and the ONU's ID (i.e. identifier) is 
pre-registered (i.e. previously stored)); 

(C) instructions which, when executed by said processor, cause transmission of 
an authentication success packet to the ONU when it is determined that the 
correspondence exists (page 13, this being one possible EAP Success/Failure 
message); and 

(D) instructions which, when executed by said processor, cause transmission of 
an authentication failure packet to the ONU when it is determined that the 
correspondence does not exist (age 13, this being the other possible EAP 
Success/Failure message), but does not specifically teach (E) instructions which, when 
executed by said processor, control the OLT to inform, after execution of the (C) 
instructions or the (D) instructions, the ONU that an authentication process has ended. 

However, See teaches (E) instructions which, when executed by said processor, 
control the OLT to inform, after execution of the (C) instructions or the (D) instructions, 
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the ONU that an authentication process has ended (column 6, lines 22-30, this being 
the authentication session termination message). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to send an explicit indication that 
authentication has ended as in See because this would allow the ONU to begin to fix an 
authentication problem (if a failure) or begin regular communications (if a success). 

As to claim 16, Kim teaches wherein the identifier of the ONU is a username 
(page 13, the ONU's pre-registered ID being a username). 

As to claim 18, Kim teaches computer-readable recording medium having, 
recorded within, a program executable by a processor of an optical network unit (ONU) 
of an Ethernet passive optical network (EPON), the program comprising: 

(A) instructions which, when executed by said processor, control an optical 
network unit (ONU) to transmit, to an optical line terminal (OLT), a packet informing of 
the start of an authentication process, and causing the ONU to receive, from the OLT, a 
packet for requesting an identifier of the ONU (page 13, this being the EAPOL-Start and 
EAP request(who) messages respectively); 

(B) instructions which, when executed by said processor, control the ONU to 
transmit to the OLT the identifier of the ONU (page 1 3, this being the EAP 
Response/ld(mylD)); 
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(C) instructions which, when executed by said processor, cause the ONU to 
receive an authentication success packet in response to transmission of the 
authentication success packet when it is determined that a correspondence exists 
between the identifier and a value previously stored in the OLT, and proceeding with 
processing at the ONU based on that determination (page 13, this being one possible 
EAP Success/Failure message and the ONU's ID (i.e. identifier) is pre-registered (i.e. 
previously stored)); and 

(D) instructions which, when executed by said processor, cause the ONU to 
receive an authentication success packet in response to transmission of the 
authentication failure packet when it is determined that the correspondence does not 
exist, and proceeding with processing at the ONU based on the determination that the 
correspondence does not exist (page 13, this being the other possible EAP 
Success/Failure message), but does not specifically teach (E) instructions which, when 
executed by said processor, cause the ONU to receive, from the OLT, a packet 
informing that an authentication process has ended, the informing packet being sent as 
a result of the determination that the correspondence does or does not exist. 

However, See teaches (E) instructions which, when executed by said processor, 
cause the ONU to receive, from the OLT, a packet informing that an authentication 
process has ended, the informing packet being sent as a result of the determination that 
the correspondence does or does not exist (column 6, lines 22-30, this being the 
authentication session termination message). 
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Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to send an explicit indication that 
authentication has ended as in See because this would allow the ONU to begin to fix an 
authentication problem (if a failure) or begin regular communications (if a success). 

As to claim 19, Kim teaches wherein the identifier of the ONU is a username 
(page 13, the ONU's pre-registered ID being a username). 

15. Claims 3-6, 9-12, 17, and 20 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Kim in view of See in further view of "Authentication and Encryption 
in EPON" (hereinafter "Murakami") in further view of Gentry. 

As to claim 3, Kim teaches wherein each of the packets used in the 
authentication method includes: 

a destination address (DA) field for indicating a destination of the packet (page 6, 

DA); 

a source address (SA) field for indicating a source of the packet (page 6); 
a logical link identifier (LLID) field for indicating an LLID (page 6); 
a type field for indicating an Ethertype of the packet (page 6, L/Type); 

a data/protocol data unit (PDU) field for indicating data of the packet (page 6); 

and 
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a frame check sequence (FCS) field for indicating FCS information for detecting 
errors of a frame, corresponding to the packet, included in information to be transmitted 
in the unit of frames, the FCS information being arranged at a tail end of the frame 
(page 6), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets; nor 

a version field for indicating version information of the packet; 

a code field for indicating an authentication operation based on the packet. 

However, Murakami teaches a version field for indicating version information of 
the packet (page 4, Protocol version); 

a code field for indicating an authentication operation based on the packet (page 
4, Code), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets. 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include version and code fields as 
in Murakami because it is an extension of EAP which "can be applied to EPON easily" 
(Murakami, page 4). 

Furthermore, Gentry teaches a sub-type field for identifying the packet when its 
type field is identical to those of other packets (page 4, subtype). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include a sub-type field as in 
Gentry because it effectively allows an expansion of the type field without requiring a 
complete redefinition thereof. 
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As to claim 4, Kim teaches wherein the code field includes: 

a value "0x01" for indicating a request for authentication contents (inherent, as 
Kim uses EAP, see RFC 2284, page 5, this being a Request); and 

a value "0x02" for indicating transmission of authentication contents (inherent, as 
Kim uses EAP, see RFC 2284, page 5, this being a Response), but does not specifically 
teach a value "0x00" for indicating start of an authentication process; 

a value "0x03" for indicating the end of an authentication process; 

a value "0x04" for indicating authentication success; nor 

a value "0x05" for indicating authentication failure. 

However, at the time the invention was made, it would have been an obvious 
matter of design choice to a person of ordinary skill in the art to alter and extend the 
Codes defined in RFC 2284 because Applicant has not disclosed that altering and 
extending the Codes defined in RFC 2284 provides an advantage, is used for a 
particular purpose, or solves a stated problem. One of ordinary skill in the art, 
furthermore, would have expected Applicant's invention to perform equally well with 
either the existing standard for the Code field (see RFC 2284, page 5, where Success 
(i.e. 0x04) is conventionally 0x03 and Failure (i.e. 0x05) is conventionally 0x04, the 
start of an authentication (i.e. 0x00) being traditionally indicated by a completely 
separate type of packet (EAP-Start) and See teaching the authentication session 
termination message (i.e. 0x03)) or rearranging the existing code types and specifying 
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two additional ones because both methods allow the OLT and ONU to effectively 
communicate for the purposes of authentication. 

Therefore, it would have been an obvious matter of design choice to modify Kim 
to obtain the invention as specified in claim 4. 

As to claim 5, Kim teaches wherein each of the packets used in the 
authentication method includes: 

a destination address (DA) field for indicating a destination of the packet (page 6, 

DA); 

a source address (SA) field for indicating a source of the packet (page 6); 
a logical link identifier (LLID) field for indicating an LLID (page 6); 
a type field for indicating an Ethertype of the packet (page 6, L/Type); 

a data/protocol data unit (PDU) field for indicating data of the packet (page 6); 

and 

a frame check sequence (FCS) field for indicating FCS information for detecting 
errors of a frame, corresponding to the packet, included in information to be transmitted 
in the unit of frames, the FCS information being arranged at a tail end of the frame 
(page 6), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets; nor 

a version field for indicating version information of the packet; 

a code field for indicating an authentication operation based on the packet. 
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However, Murakami teaches a version field for indicating version information of 
the packet (page 4, Protocol version); 

a code field for indicating an authentication operation based on the packet (page 
4, Code), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets. 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include version and code fields as 
in Murakami because it is an extension of EAP which "can be applied to EPON easily" 
(Murakami, page 4). 

Furthermore, Gentry teaches a sub-type field for identifying the packet when its 
type field is identical to those of other packets (page 4, subtype). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include a sub-type field as in 
Gentry because it effectively allows an expansion of the type field without requiring a 
complete redefinition thereof. 

As to claim 6, Kim teaches wherein the code field includes: 
a value "0x01" for indicating a request for authentication contents (inherent, as 
Kim uses EAP, see RFC 2284, page 5, this being a Request); and 

a value "0x02" for indicating transmission of authentication contents (inherent, as 
Kim uses EAP, see RFC 2284, page 5, this being a Response), but does not specifically 
teach a value "0x00" for indicating start of an authentication process; 
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a value "0x03" for indicating the end of an authentication process; 
a value "0x04" for indicating authentication success; nor 
a value "0x05" for indicating authentication failure. 

However, at the time the invention was made, it would have been an obvious 
matter of design choice to a person of ordinary skill in the art to alter and extend the 
Codes defined in RFC 2284 because Applicant has not disclosed that altering and 
extending the Codes defined in RFC 2284 provides an advantage, is used for a 
particular purpose, or solves a stated problem. One of ordinary skill in the art, 
furthermore, would have expected Applicant's invention to perform equally well with 
either the existing standard for the Code field (see RFC 2284, page 5, where Success 
(i.e. 0x04) is conventionally 0x03 and Failure (i.e. 0x05) is conventionally 0x04, the 
start of an authentication (i.e. 0x00) being traditionally indicated by a completely 
separate type of packet (EAP-Start) and See teaching the authentication session 
termination message (i.e. 0x03)) or rearranging the existing code types and specifying 
two additional ones because both methods allow the OLT and ONU to effectively 
communicate for the purposes of authentication. 

Therefore, it would have been an obvious matter of design choice to modify Kim 
to obtain the invention as specified in claim 6. 

As to claim 9, Kim teaches wherein each of the packets used in the 
authentication method includes: 
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a destination address (DA) field for indicating a destination of the packet (page 6, 

DA); 

a source address (SA) field for indicating a source of the packet (page 6); 
a logical link identifier (LLID) field for indicating an LLID (page 6); 
a type field for indicating an Ethertype of the packet (page 6, L/Type); 

a data/protocol data unit (PDU) field for indicating data of the packet (page 6); 

and 

a frame check sequence (FCS) field for indicating FCS information for detecting 
errors of a frame, corresponding to the packet, included in information to be transmitted 
in the unit of frames, the FCS information being arranged at a tail end of the frame 
(page 6), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets; nor 

a version field for indicating version information of the packet; 

a code field for indicating an authentication operation based on the packet. 

However, Murakami teaches a version field for indicating version information of 
the packet (page 4, Protocol version); 

a code field for indicating an authentication operation based on the packet (page 
4, Code), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets. 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include version and code fields as 
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in Murakami because it is an extension of EAP which "can be applied to EPON easily" 
(Murakami, page 4). 

Furthermore, Gentry teaches a sub-type field for identifying the packet when its 
type field is identical to those of other packets (page 4, subtype). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include a sub-type field as in 
Gentry because it effectively allows an expansion of the type field without requiring a 
complete redefinition thereof. 

As to claim 10, Kim teaches wherein the code field includes: 

a value "0><01" for indicating a request for authentication contents (inherent, as 
Kim uses EAP, see RFC 2284, page 5, this being a Request); and 

a value "0><02" for indicating transmission of authentication contents (inherent, as 
Kim uses EAP, see RFC 2284, page 5, this being a Response), but does not specifically 
teach a value "0x00" for indicating start of an authentication process; 

a value "0x03" for indicating the end of an authentication process; 

a value "0x04" for indicating authentication success; nor 

a value "0x05" for indicating authentication failure. 

However, at the time the invention was made, it would have been an obvious 
matter of design choice to a person of ordinary skill in the art to alter and extend the 
Codes defined in RFC 2284 because Applicant has not disclosed that altering and 
extending the Codes defined in RFC 2284 provides an advantage, is used for a 
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particular purpose, or solves a stated problem. One of ordinary skill in the art, 
furthermore, would have expected Applicant's invention to perform equally well with 
either the existing standard for the Code field (see RFC 2284, page 5, where Success 
(i.e. 0x04) is conventionally 0x03 and Failure (i.e. 0x05) is conventionally 0x04, the 
start of an authentication (i.e. 0x00) being traditionally indicated by a completely 
separate type of packet (EAP-Start) and See teaching the authentication session 
termination message (i.e. 0x03)) or rearranging the existing code types and specifying 
two additional ones because both methods allow the OLT and ONU to effectively 
communicate for the purposes of authentication. 

Therefore, it would have been an obvious matter of design choice to modify Kim 
to obtain the invention as specified in claim 10. 

As to claim 1 1 , Kim teaches wherein each of the packets used in the 
authentication method includes: 

a destination address (DA) field for indicating a destination of the packet (page 6, 

DA); 

a source address (SA) field for indicating a source of the packet (page 6); 
a logical link identifier (LLID) field for indicating an LLID (page 6); 
a type field for indicating an Ethertype of the packet (page 6, L/Type); 

a data/protocol data unit (PDU) field for indicating data of the packet (page 6); 

and 
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a frame check sequence (FCS) field for indicating FCS information for detecting 
errors of a frame, corresponding to the packet, included in information to be transmitted 
in the unit of frames, the FCS information being arranged at a tail end of the frame 
(page 6), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets; nor 

a version field for indicating version information of the packet; 

a code field for indicating an authentication operation based on the packet. 

However, Murakami teaches a version field for indicating version information of 
the packet (page 4, Protocol version); 

a code field for indicating an authentication operation based on the packet (page 
4, Code), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets. 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include version and code fields as 
in Murakami because it is an extension of EAP which "can be applied to EPON easily" 
(Murakami, page 4). 

Furthermore, Gentry teaches a sub-type field for identifying the packet when its 
type field is identical to those of other packets (page 4, subtype). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include a sub-type field as in 
Gentry because it effectively allows an expansion of the type field without requiring a 
complete redefinition thereof. 



Application/Control Number: 10/763,872 
Art Unit: 2436 



Page 22 



As to claim 12, Kim teaches wherein the code field includes: 

a value "0x01" for indicating a request for authentication contents (inherent, as 
Kim uses EAP, see RFC 2284, page 5, this being a Request); and 

a value "0x02" for indicating transmission of authentication contents (inherent, as 
Kim uses EAP, see RFC 2284, page 5, this being a Response), but does not specifically 
teach a value "0x00" for indicating start of an authentication process; 

a value "0x03" for indicating the end of an authentication process; 

a value "0x04" for indicating authentication success; nor 

a value "0x05" for indicating authentication failure. 

However, at the time the invention was made, it would have been an obvious 
matter of design choice to a person of ordinary skill in the art to alter and extend the 
Codes defined in RFC 2284 because Applicant has not disclosed that altering and 
extending the Codes defined in RFC 2284 provides an advantage, is used for a 
particular purpose, or solves a stated problem. One of ordinary skill in the art, 
furthermore, would have expected Applicant's invention to perform equally well with 
either the existing standard for the Code field (see RFC 2284, page 5, where Success 
(i.e. 0x04) is conventionally 0x03 and Failure (i.e. 0x05) is conventionally 0x04, the 
start of an authentication (i.e. 0x00) being traditionally indicated by a completely 
separate type of packet (EAP-Start) and See teaching the authentication session 
termination message (i.e. 0x03)) or rearranging the existing code types and specifying 
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two additional ones because both methods allow the OLT and ONU to effectively 
communicate for the purposes of authentication. 

Therefore, it would have been an obvious matter of design choice to modify Kim 
to obtain the invention as specified in claim 12. 

As to claim 17, Kim teaches wherein each of the packets used in the 
authentication method includes: 

a destination address (DA) field for indicating a destination of the packet (page 6, 

DA); 

a source address (SA) field for indicating a source of the packet (page 6); 
a logical link identifier (LLID) field for indicating an LLID (page 6); 
a type field for indicating an Ethertype of the packet (page 6, L/Type); 

a data/protocol data unit (PDU) field for indicating data of the packet (page 6); 

and 

a frame check sequence (FCS) field for indicating FCS information for detecting 
errors of a frame, corresponding to the packet, included in information to be transmitted 
in the unit of frames, the FCS information being arranged at a tail end of the frame 
(page 6), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets; nor 

a version field for indicating version information of the packet; 

a code field for indicating an authentication operation based on the packet. 
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However, Murakami teaches a version field for indicating version information of 
the packet (page 4, Protocol version); 

a code field for indicating an authentication operation based on the packet (page 
4, Code), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets. 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include version and code fields as 
in Murakami because it is an extension of EAP which "can be applied to EPON easily" 
(Murakami, page 4). 

Furthermore, Gentry teaches a sub-type field for identifying the packet when its 
type field is identical to those of other packets (page 4, subtype). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include a sub-type field as in 
Gentry because it effectively allows an expansion of the type field without requiring a 
complete redefinition thereof. 

As to claim 20, Kim teaches wherein each of the packets used in the 
authentication method includes: 

a destination address (DA) field for indicating a destination of the packet (page 6, 

DA); 

a source address (SA) field for indicating a source of the packet (page 6); 
a logical link identifier (LLID) field for indicating an LLID (page 6); 
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a type field for indicating an Ethertype of the packet (page 6, L/Type); 

a data/protocol data unit (PDU) field for indicating data of the packet (page 6); 

and 

a frame check sequence (FCS) field for indicating FCS information for detecting 
errors of a frame, corresponding to the packet, included in information to be transmitted 
in the unit of frames, the FCS information being arranged at a tail end of the frame 
(page 6), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets; nor 

a version field for indicating version information of the packet; 

a code field for indicating an authentication operation based on the packet. 

However, Murakami teaches a version field for indicating version information of 
the packet (page 4, Protocol version); 

a code field for indicating an authentication operation based on the packet (page 
4, Code), but does not specifically teach a sub-type field for identifying the packet when 
its type field is identical to those of other packets. 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include version and code fields as 
in Murakami because it is an extension of EAP which "can be applied to EPON easily" 
(Murakami, page 4). 

Furthermore, Gentry teaches a sub-type field for identifying the packet when its 
type field is identical to those of other packets (page 4, subtype). 
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Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify Kim to include a sub-type field as in 
Gentry because it effectively allows an expansion of the type field without requiring a 
complete redefinition thereof. 

Conclusion 

16. The following prior art made of record and not relied upon is cited to establish the 
level of skill in the applicant's art and those arts considered reasonably pertinent to 
applicant's disclosure. See MPEP 707.05(c). 

U.S. Patent Application Pub. No. US 2004/0073788 A1 (Kim) 
"MPCP: Multi-Point Control Protocol for EPONs" (Gaglianello) 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Travis Pogmore whose telephone number is (571)270- 
7313. The examiner can normally be reached on Monday through Thursday between 
8:30 a.m. and 4:00 p.m. eastern time. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Thomas Pham can be reached on 571-272-3689. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

U. P.I 

Examiner, Art Unit 2436 



/Thomas K Pham/ 
Supervisory Patent Examiner, Art Unit 4148 



